IBIS Macromodel Task Group Meeting date: 17 September 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Altair: * Junesang Lee Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma * Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak Kinger Cai Chi-te Chen Liwei Zhao Alaeddin Aydiner Sai Zhou Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang * Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Samsung: Jun-Bae Kim Siemens EDA (Mentor): * Arpad Muranyi Randy Wolff Signal Edge Solutions * Benjamin Dannan Teraspeed Labs: [Bob Ross] Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Junesang (Jaden) Lee introduced himself to the group. He joined the mailing list several years ago, and he is working on creating IBIS AMI solutions for Altair. ------------- Review of ARs: Yifan: Send her "IBIS SPICE validation" presentation slides to ATM. - Done. Yifan: Prepare a new draft of BIRD220.1 with a description of the limitation of the algorithm. - Done. Michael: Send out an updated Ts4file proposal containing changes discussed in the meeting. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 10th meeting. Michael moved to approve the minutes. Jared seconded the motion. There were no objections. -------------- New Discussion: BIRD220.1 update: Yifan said that she had sent out an updated draft of BIRD220.1. She asked whether anyone had any feedback or if the draft was ready for the Open Forum. Arpad recalled the SPICE driver model containing separate pre-driver paths for the pullup and pulldown transistors, which he had previously provided Yifan for testing. He reviewed a set of rising and falling transitions he had previously generated with the SPICE model driving a resistive load into various V_fixture values. He noted that the rising edges for values of V_fixture between Vss and Vdd showed a plateau in the middle of the transition at the V_fixture value. He said the plateau was the period when neither transistor was active, as the transistor turning off is shut off before the other transistor is turned on, to minimize crowbar currents. He asked whether the presence of the plateau might indicate to the model maker when a device is not suitable for application of BIRD220.1. However, he noted that the falling edges showed significantly smaller plateaus, so he wasn't sure this technique would work. Is it really just a question of pre-driver timing that alone determines whether BIRD220.1 will work? Yifan agreed to investigate and provide an update. Ts4file and [Ramp]: Michael recalled that the previous meeting's discussion had ranged widely and covered topics such as whether [Ramp] should still be required in all cases, the language in the specification describing the purpose of [Ramp], and whether [Ramp] data must be consistent with any non-traditional model information such as Ts4file and [External Model]. Michael asked whether we want to maintain [Ramp] as a required keyword, even for non-traditional models (e.g., models using Ts4file or [External Model]). He asked whether [Ramp] has much utility in the context of non-traditional models. He recalled Ambrish's comment that we essentially reinvented the definition of [Ramp] when it is used with [External Model] (IBIS 7.2, pg. 136): ...within the scope of [External Model], the [Ramp] keyword is intended strictly to provide EDA tools with a quick first-order estimate of driver switching characteristics. Michael said any new language about [Ramp] in the context of Ts4file should follow that precedent. Michael said that if we decide [Ramp] is no longer required, then many of our issues with language and checking go away. If, however, we continue to say [Ramp] is required, then how do we make sure it's valid and define what has to match with other data in the model? Arpad recalled that at the previous meeting he, Walter and others had agreed that the keyword itself should still be required. However, there was no agreement to require the [Ramp] data to match Ts4file, [External Model], etc. Arpad said he had sent an email with some new thoughts on this topic. He proposed that we extend the language used in [External Model] to Ts4file and traditional I-V and V-t table models. He said that [Ramp] is the primary source of information only when nothing else exists (i.e., a model with no I-V tables, no Ts4file, no [External Model]). Fangyi provided a counterexample. What if a model includes only Ts4file and [Ramp]? In that case, the [Ramp] is the only source of data for a non-AMI simulation. Arpad said the question is whether the Ts4file can be used in a non-AMI simulation. Fangyi noted that the specification currently says Ts4file is "exclusively limited to AMI applications" (IBIS 7.2, pg. 316). Arpad acknowledged the language, but said it's still an open question. Walter said the language does not forbid an EDA tool from using Ts4file in any context. Arpad asked, for a normal non-AMI simulation, are we allowed to use the Ts4file? Walter said that if I-V tables were also included in the model, then he would use those in a non-AMI simulation. However, if Ts4file was the only thing other than [Ramp], then he would use the Ts4file data. It's up to the tool or user to decide which to use, but a model that only has [Ramp] isn't very useful. Arpad said we might need to change the "exclusively limited to AMI applications" language if everyone agrees with Walter's interpretation. Walter said that I-V and V-t tables, [External Model], and Ts4file are three independent representations of a model's data. The only thing they have in common is that [Ramp] is intended to provide a first order estimate of band- width information in all three cases. Walter said the parser should continue checking [Ramp] vs. static I-V table data (if it's provided), but [Ramp] should not be checked against Ts4file or [External Model]. He said for Ts4file and [External Model] the dt portion of [Ramp] provides a bandwidth estimate, and we need not check it. Arpad noted that even for I-V and V-t models the parser only checks the dV portion of the [Ramp] against what would be expected hooking the I-V tables up to the same load. He said the [Ramp] dt can't really be checked against the V-t waveforms anyway. He noted that we typically have two rising waveforms, for example, with one for a load to Vcc and one for a load to ground. He said one of those waveforms is likely dominated by the pulldown turning off, and the other is dominated by the pullup turning on. So, a single [Ramp] dt value likely can't match both of them. Michael said that if we're willing to allow I-V and V-t data to be completely independent of Ts4file and not subject to any check for consistency, then that is likely the easiest solution for us currently. However, it probably means that EDA tools can't take the [Ramp] data too literally in the context of non- traditional models. - Michael: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: Yifan: Investigate with Arpad's SPICE circuit to see whether characteristics of rising and falling edges can help a model maker decide whether BIRD220.1 is applicable. ------------- Next meeting: 24 September 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives